This invention relates generally to the field of selecting one or more tests for a compiled software module, and more particularly to strategizing automated software test coverage by leveraging a rule system.
In software development, in order to give development teams early feedback about the quality of the code being developed, teams are adopting continuous integration practices. These practices call for building authored software modules very frequently, often several times a day. Building a module means compiling it, but also executing a set of tests which are required to succeed in order to “accept” the module, that is, publish the compiled artifact to a central repository from where dependent modules can pull the module. When developing large applications, the volume of tests that are executed during the build of all modules can become significant.
A typical continuous integration environment consists of several elements including a source code management system, a build management system and a compiled artifact repository. The source code management system is used by developers to check code out, and commit their change set in. This keeps track of all versions of each file, as well as the identification of the developer associated with each change. Most source code management systems also include a notification mechanism, which can notify downstream systems that a change set was committed. At a minimum, a source code management system includes a way to query for change sets.
A build management system can be either centralized or distributed. In both cases, the build management system queries, or is notified by, the source code management system, in order to aggregate a list of the new change sets that have been committed since the time of the last build cycle. The build management system can then check out these changes to obtain a local copy of the source code which represents the latest version of the versioned source files and trigger a build cycle, which contains generally three sub-steps. The first sub-step is compilation of the various source files, from the source programming language(s) to machine executable code. This includes compilation of the test code. The second sub-step is execution of all or some tests on the compiled code, capturing the results of the tests (success or failure for each test). The third sub-step, based upon a success criteria, is publication of the compiled artifact to a central repository. The success criteria can be the success of all, or a fraction of the tests executed, depending on the team choice.
A compiled artifact repository is a system that hosts a series of versions of compiled source code, so that dependent modules can use the latest known good version of a compiled artifact they depend on, instead of having to compile it themselves.